Release 10.1A: OpenEdge Application Server:
Developing WebSpeed Applications

Modifying the request logic

The default process-web-request logic orders the procedure calls around a single test of the CGI REQUEST_METHOD variable. Aside from customizing the procedures themselves, you can (and often must) change the placement of these procedure calls in the logic, depending on your application. You can also add other tests for submit button values or other data that is returned with each request.

Typically, you have a GET when the browser user clicks a link or enters a URL to the Web object. Although you can create an HTML form that returns with another GET, limitations on the amount of data that a browser can return with a GET make a POST request the preferred choice. A GET passes data as part of the URL, while a POST passes data through the agent’s standard input.

However, as the comments in process-web-request indicate (see Chapter 2 "Web Objects"), a GET request has other possible uses. If you want to return a different Web page from the one that was just posted, the Web object that handles the post has to call another Web object to provide the new page. You might do this after handling the current POST (STEP 3) and before you ordinarily begin to return the current form (STEP 4.2a). This is the missing STEP 4.1.

But when you call the new Web object, you want it called as if it were handling a CGI GET request, so it will return the new page as if for the first time. To simulate a GET request, WebSpeed allows you to assign the Web object REQUEST_METHOD variable to change the method (in this case from a POST to a GET) before you call the new Web object.

Note: While you can modify REQUEST_METHOD, this is not always a safe practice.

What about the data passed in with the actual POST? WebSpeed internally treats a GET or POST the same way. That is, when it retrieves data values input with the request, it always looks for data from a posted form in both the URL (retrieved from the CGI QUERY_STRING variable) and the standard input. Thus, you can change the request method for a called Web object to a GET and still allow the object to retrieve any data that came in with the previous POST.

Note: If you change the request method from a POST to a GET for a called Web object, it is up to you to change the request method back to a POST when the Web object returns to the caller.

You can also retrieve data independently of the apparent request method. For this purpose, WebSpeed provides the get-value( ) API function. This function returns the value for any named item, whether it comes from QUERY_STRING or the standard input.

Because Web objects do not care where their input comes from, you can write a WebSpeed application that bases its request logic solely on the values returned by the get-value() API function and ignore the inputFields method entirely or provide a local inputFields override.

Note: Unless you want to reset REQUEST_METHOD, or if the secondary Web object is state aware, you can run the secondary Web object directly.